Application Programming Interfaces (APIs) are generally employed to provide connectivity between applications and underlying data in a system or services provided by an entity or institution. Conventional authentication systems and processes for an API typically consider a single factor, trust between applications. Authentication is generally termed as the act of confirming the identity of a client or caller.
In a conventional authentication model, a client may request access to a restricted resource (protected resource) on a site (e.g., a server) by authenticating with the server via a portal or website using the resource owner's credentials. To provide third party applications (via an API) access to these restricted resources, the resource owner must share its credentials with the third party which may result in several problems. For example, in such conventional authentication models the applications and/or APIs may be required to store the resource owner's credentials (e.g., password) for future use and servers must support password authentication, despite the security weaknesses inherent in passwords. Additionally, in such conventional models applications and/or APIs may gain broad access to a resource owner's protected resources, leaving resource owners without an ability to restrict duration or access to a limited subset of resources. Thus, resource owners may not be able to revoke access to an individual third party without revoking access to all third parties, and any compromise of an API may result in the compromise of a user's password and all data protected thereby.
Additional methods or forms of authentication also exist in the industry. For example, OpenID is an open standard that describes how a user may be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities. More specifically, in such a method a user may interact with a relying party (via a website) that provides an option to specify an OpenID for the purposes of authentication. An identity provider, or OpenID provider (OP), is a service that specializes in registering OpenID uniform resource locators (URLs) or extensible resource identifiers (XRIs). OpenID may then enable a user to communicate with a relying party through the exchange of an identifier or OpenID corresponding to the URL or XRI chosen to name the user's identity. An OP may provide the OpenID authentication (and possibly other identity services) which is enabled by a user-agent (e.g., a program such as a browser) employed by the end-user to communicate with the relying party and OP. By way of further example, OAuth 2.0 is another open standard for authorization which allows a resource owner or user to share private resources between two sites without having to provide a user's credentials to the relying party. More specifically, OAuth 2.0 provides an authorization framework enabling a third party application or API to obtain access to a service, on behalf of a user by orchestrating an approval interaction between the user and the service or by allowing the third party application or API to obtain access on its own behalf. OAuth 2.0 typically introduces an authorization layer and separates the role of a client (i.e., online service, etc.) from that of the user or resource owner. In OAuth 2.0, a client generally requests access to resources controlled by the user and hosted by a resource server and is issued a different set of credentials than those of the user. Instead of employing the user's credentials to access protected resources, a client may obtain an access token (i.e., a string denoting a specific scope, lifetime, or other access attribute). Access tokens are issued to clients by an authorization server with the approval of the user whereby the client uses the access token to access the protected resources hosted by the resource server. For example, a user or resource owner may grant a banking service (i.e., client) access to the user's account or other information stored at resource server without sharing the user's username and password with the banking service. Rather, the user may authenticate directly with a server trusted by the banking service (i.e., an authorization server) which issues an appropriate access token.
These forms of authentication, however, are still susceptible to certain attacks on supporting systems including phishing attacks, malicious applications, and the like. Thus, there remains a need to overcome conventional limitations and provide an API to securely support both internally and externally created applications which provide access to, for example, a user's financial data or services provided by an entity or institution.